watch: fix stale watcher state across log rotation - #6

Fixes the two test_log_rotate failure modes seen in tt CI after the v1.4.14 bump (first master run, 2/42 parametrizations, delay_time=0.01):

• duplicated first line after rotation — a watch armed while the file was being replaced took its size baseline from the tailer's offset in the old file (fw.Size = pos). The first write to the new, smaller file then looked like a truncation, and the spurious reopen re-read the file from offset zero, re-delivering the lines already sent. A second path to the same symptom: the pendingReopen/Truncated branches kept tail.changes across reopen(); when the rename fired right after the arming, the kept subscription was already dead with a latched Deleted notification, which triggered a bogus second reopen.
• tailer hangs, zero lines delivered — a watcher goroutine whose events channel was closed externally exited silently and removed the watch a second time, driving the shared refcount negative; the tailer blocked forever on a subscription that could not fire, and every later watch of the same name skipped the fsnotify subscription entirely.

The fix:

• ChangeEvents seeds the size baseline (and the recorded inode) from a stat of the file at arm time. In-window changes are the recheck's job (that is what it is for); the watcher only needs a baseline consistent with the file it actually watches.
• every reopen path (pendingDelete, pendingReopen, Truncated) drops the subscription via the new synchronous FileChanges.Stop() and re-arms it on the next EOF. The producer goroutine is stopped with a handshake before re-arming — an abandoned live producer would keep consuming from the shared per-file events channel, stealing events from the fresh subscription (this is why a bare tail.changes = nil would not be a safe fix).
• a producer that finds its events channel closed reports the file as deleted instead of exiting silently, and removeWatch refuses to drive the refcount below zero.
• pendingReopen is cleared when a pending delete performs the reopen, so a stale flag cannot cause one more reopen cycle later.

Regression tests (all reproduce on v1.4.14 on Linux, deterministically, via the existing delayBeforeWatch knob and the new delayBeforeRecheck knob; both inotify and polling watchers where applicable):

• TestReplaceWhileArmingThenAppend, TestTruncateWhileArmingThenAppend — stale baseline → spurious truncation → duplication;
• TestReplaceWhileRecheckingThenAppend — dead watch kept across pendingReopen → double reopen → duplication;
• TestExternalWatchRemovalDoesNotHang — silent producer death → permanent hang;
• TestRotationStressExactlyOnce — 20 rotations × 5 lines at 5 ms cadence, exactly-once delivery.

Verified: full suite with -race on Linux (docker, arm64) and macOS; new tests looped ×50 (stress) and ×8 (deterministic) plus ×10 under -race with zero flakes.

Part of TNTP-3131